60장. EFS · FSx — 공유 파일 시스템
이 장에서 말하고자 하는 것
S3는 객체 스토리지지, “공유 파일 시스템” 이 아니다.
여러 서버가 같은 폴더를 마운트해서 동시에 읽고 쓸 때 필요한 도구가
EFS · FSx
다.
- 워드프레스 같은 PHP 앱
- 머신러닝 데이터셋
- 빌드 캐시 공유
- 일부 미디어 처리 파이프라인
1. EFS는 무엇인가
EFS(Elastic File System)는
여러 EC2 / 컨테이너가 동시에 마운트하는 NFS
- NFSv4 프로토콜
- 멀티 AZ
- 자동 확장 (용량 신경 안 써도 됨)
- 사용한 만큼 과금
POSIX 파일 시스템처럼 동작한다.
2. FSx — 더 특수한 영역
- FSx for Lustre — 고성능 HPC, 머신러닝
- FSx for Windows — SMB (윈도우 공유)
- FSx for NetApp ONTAP / OpenZFS — 엔터프라이즈 NAS 호환
일반 리눅스 서비스의 공유 파일은 EFS
윈도우 / 고성능 / NAS 호환은 FSx
3. EFS의 성능 모드와 처리량
성능 모드:
General Purpose : 대부분 (지연 짧음)
Max I/O : 동시 접근 많음 (지연 약간 큼)
처리량 모드:
Bursting : 보통 워크로드
Provisioned : 일정한 고처리량
Elastic : 자동 (최근 권장)
처음에는 General Purpose + Elastic 으로 시작.
4. EFS의 스토리지 클래스
S3처럼 EFS도 클래스가 있다.
EFS Standard
EFS Standard-IA (30일 미접근 자동 이동)
EFS One Zone
EFS One Zone-IA
수명 주기를 켜두면 거의 안 만지는 파일이 자동으로 IA로.
5. ECS / Fargate에서 EFS 쓰기
Fargate는 EFS를 직접 마운트할 수 있다.
Task Definition
└─ volumes
└─ efsVolumeConfiguration
- fileSystemId: fs-xxxx
- rootDirectory: /shared
└─ containerDefinitions[].mountPoints
└─ /app/data
컨테이너 안에서 /app/data 가 EFS의 /shared 가 된다.
다만 컨테이너 시대에 EFS는 자주 쓰는 도구는 아니다
대부분 S3 + RDS · DynamoDB 로 풀린다
6. 언제 쓰지 말아야 하는가
- 데이터베이스 (EBS 또는 관리형 DB)
- 매우 작은 IO를 매우 자주 (NFS 오버헤드 누적)
- “그냥 파일 저장” — 이건 S3
EFS는 “공유” 가 핵심이다. 공유가 필요 없다면 EFS 쓸 이유가 없다
7. 우리 서비스에서
이 책의 척추 구조는 EFS를 기본으로 두지 않는다.
- 사용자 업로드 → S3
- 정적 자원 → S3
- DB → RDS · DynamoDB
- 로그 → CloudWatch / S3
EFS는 “공유 파일이 진짜 필요할 때” 이름을 떠올리는 도구
8. 직접 확인해보기 — CLI
aws efs create-file-system \
--performance-mode generalPurpose \
--throughput-mode elastic
aws efs create-mount-target \
--file-system-id fs-xxxx \
--subnet-id subnet-xxxx \
--security-groups sg-xxxx
# EC2에서 마운트
sudo mount -t nfs4 -o nfsvers=4.1 \
fs-xxxx.efs.ap-northeast-2.amazonaws.com:/ \
/mnt/efs
9. 코드로는 이렇게 생겼다 — Terraform
resource "aws_efs_file_system" "shared" {
performance_mode = "generalPurpose"
throughput_mode = "elastic"
lifecycle_policy {
transition_to_ia = "AFTER_30_DAYS"
}
}
resource "aws_efs_mount_target" "a" {
file_system_id = aws_efs_file_system.shared.id
subnet_id = aws_subnet.private_a.id
security_groups = [aws_security_group.efs.id]
}
resource "aws_efs_mount_target" "b" {
file_system_id = aws_efs_file_system.shared.id
subnet_id = aws_subnet.private_b.id
security_groups = [aws_security_group.efs.id]
}
각 AZ마다 Mount Target을 둬야 한다는 게 핵심.
10. 이렇게 쓰면 망한다 — 안티패턴
안티패턴 1. EFS를 DB 저장소로 쓴다
NFS의 fsync 동작이 DB와 충돌. 데이터 손상 가능.
안티패턴 2. Mount Target을 한 AZ만 둔다
다른 AZ의 컨테이너가 못 붙는다.
안티패턴 3. 보안 그룹을 잘못 잡는다
EFS SG는 NFS 포트(2049) 를 클라이언트 SG에서 허용해야 한다.
안티패턴 4. 작은 파일을 초고빈도로 읽는다
NFS 오버헤드 누적. 캐시 / 로컬 디스크가 맞다.
11. 한 줄로 정리
EFS는 여러 컴퓨트가 동시에 마운트하는 NFS 공유이며,
S3나 DB가 답이 안 될 때만 등장하는 도구다
12. 이 장의 핵심 정리
- EFS는 NFS 기반의 공유 파일 시스템이다.
- FSx는 Lustre · Windows · NetApp 같은 특수 옵션이다.
- 컨테이너 시대에는 대부분 S3로 풀린다.
- DB · 초고빈도 작은 IO에는 어울리지 않는다.
- Mount Target은 사용하는 모든 AZ에 둬야 한다.